home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 506 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.3 KB
  1. From: David Byrden <100101.2547@compuserve.com>
  2. Message-ID: <4g0civ$dq5@news.bridge.net>
  3. X-Original-Date: 15 Feb 1996 22:37:19 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 16 Feb 96 03:57:55 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Exceptions and Destructors
  9. Organization: self-employed
  10. References: <BGLENDEN.96Feb14173755@colobus.aoc.nrao.edu>
  11. X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMSQA3uEDnX0m9pzZAQHzmQF9Fs/RJ9HRAog0ms+1Nm3Zb91eNmh7rwUW
  14.     yTJTS9MT8HpaeOFhFN4Oh+L8RELZSPR5
  15.     =6YYZ
  16.  
  17. >>> struct foo : public other
  18. >>> {
  19. >>>     ~foo {throw("BAD?");}
  20. >>> };
  21.  
  22. >> Since the above does not result in an infinite loop on the compilers I
  23. >> have access to, I presume that the object is considered destructed
  24. >> when the dtor is entered.
  25.  
  26.  
  27.   Compilers do not serve as a reliable definition of anything. The draft 
  28. C++ standard is available at  http://www.cygnus.com/misc/wp/jan96  and 
  29. a query of it is less painful than a debugging session.   :)
  30.  
  31. A quote:
  32.  
  33. 15.3.10
  34. The  fully  constructed base classes and members of an object shall be
  35. destroyed before entering the handler of a function-try-block  of  a
  36. constructor or destructor for that object.
  37.  
  38.  
  39.   I cannot easily find any other mention of when sub-objects are 
  40. destroyed during a destructor throw. I presume that somewhere it states 
  41. that they shall be destroyed, since you could always force their 
  42. destruction by writing a function-try-block with an empty handler.
  43.  
  44.   I assume that you expected your infinite loop when a *stack* object is 
  45. destroyed, since the block in question then becomes subject to stack 
  46. unwinding. In fact, the object which threw is excluded from the 
  47. unwinding. This makes sense when you consider the situation of a block 
  48. that declares multiple local objects, and destroys them in reverse order. 
  49. If one of them throws, destruction of the whole lot does not start over 
  50. again.
  51.  
  52.  
  53.   It is generally not advisable to write destructors that throw. This can 
  54. lead to termination of the program when they do so during stack 
  55. unwinding, or when their object is a global.
  56.  
  57.  
  58.                                David
  59. ---
  60. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  61.   Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  62.   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  63.